Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-atm-classic-ip-02.txt < prev next >

Wrap

Text File | 1993-08-23 | 31.1 KB | 785 lines

Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires February 20, 1994 August 20, 1993 Classical IP and ARP over ATM Status of this Memo This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo describes an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described below and in [1]. This document does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM a as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging are beyond the scope of this paper. 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The concepts and models presented in [1], written by Dave Piscitello and Laubach [Page 1] DRAFT Classical IP and ARP over ATM August 1993 Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF and the ad hoc PVC committee at the Amsterdam meeting. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams, ARP and InARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Initial deployment of ATM provides a LAN segment replacement for ethernet networks and as wire-replacement for dedicated public telecommunication lines between IP routers. In the former model, local IP routers with one or more ATM interfaces will connect islands of local ATM networks. ATM-FORUM compliant addressing will be used within these local ATM networks. In the latter model, public ATM networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. Public networks will use ITU-TSS and ANSI standards for addressing in ATM. The characteristics and features of ATM networks are different than those found in LAN's: o ATM provides a virtual circuit switched environment. VC setup may be done on either a Permanent Virtual Circuit (PVC) or dynamic Switched Virtual Circuit (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7,9]. o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). o ATM standards provide several formats for the exchange of Protocol Data Units (PDU's), these formats are called ATM Laubach [Page 2] DRAFT Classical IP and ARP over ATM August 1993 Adaptation Layers (AAL's). When a virtual circuit is created a specific AAL type is associated with the VC. This type is specified either by administrative control for PVC's or via signalling for SVC's. There are five different AAL format types, which are commonly referred to as "AALn", where "n" is a number from one 1 through 5. There is no field in an ATM cell header which carries this AAL type value, rather it is known at each hop of the path due to the call setup mechanism. The AAL5 format specifies a packet format with a maximum size of 64K - 8 user data octets. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating end of PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. o ATM-FORUM signalling defines point-to-point and point-to- multipoint circuit setup [9]. Multipoint-to-multipoint virtual circuits are not not yet a conformance requirement of the ATM- FORUM. o ATM-FORUM local LAN addresses (in the address resolution protocol context) use the same basic format as GOSIP NSAP's [11]. Note: ATM-FORUM addresses should not be construed at being GOSIP NSAP's, they are not, the administration is different, which fields get filled out are different, etc. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. Characteristics of the classical model are: o One default maximum MTU size for the network interface, consistent with current implementations. o Default LLC/SNAP encapsulation of IP packets. o IP destinations map to VC's via ARP and end-to-end IP routing stays the same, consistent with current model. o ARP's stay within the LIS, current ARP architecture stays the same. o One IP subnet is used for many hosts and routers. A separate VC is used for each station-to-station pair, one subnet is used for all these VC's. Laubach [Page 3] DRAFT Classical IP and ARP over ATM August 1993 The "global" ATM model is an evolution of the classical model where the ATM network becomes more fully deployed and globally available. In this model, the traditional protocol stack architecture also evolves allowing applications to map directly on VC's (e.g., TCP and UDP ports map directly onto VC's) and ARP mechanisms are no longer bound to LIS boundaries as queries and replies may go global. IP will evolve to take advantage of the network services provided by the global ATM network. Characteristics of the global model are: o MTU size is negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. o IP encapsulation is negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Applications map directly to VC's, requiring changes to TCP/UDP/IP to allow ports to map directly on to VC's o ARP's are global, ARP architecture needs to change to support a robust global client/server model. o Differing quality of service (QOS) guarantees will exist on a per application and per VC basis. The deployment of ATM into the Internet community is just beginning and will take many years to complete. During the early part of this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. o Standards for global IP over ATM will take some time to complete and deploy. This memo details the treatment of the classical model of IP and ARP over ATM. There are those would like to have IP-over-ATM begin by Laubach [Page 4] DRAFT Classical IP and ARP over ATM August 1993 breaking the classical model - this memo represents the view that we must walk before we can run. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability. 6. IP Subnetwork Configuration In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LIS's over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router is a station attached to the ATM network that is configured as a member of two or more LIS's. This configuration may result in a number of disjoint LIS's operating over the same ATM network. Hosts of differing IP subnets would communicate via an intermediate router even though a direct virtual circuit between the two hosts may be available over the ATM network. The requirements for IP member stations (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All stations within an LIS are accessed directly over the ATM network. o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [4] when using SVC's. o All members within a LIS MUST be able to communicate with all other members in the same LIS; i.e., the topology is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pairs of stations. The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network. The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM address of the individual IP station. Each host must be configured to accept datagrams Laubach [Page 5] DRAFT Classical IP and ARP over ATM August 1993 destined for this address o ATM ARP Request Address (atm$arp-req). atm$arp-req is the ATM hardware address of an individual ARP server located within the LIS to which ARP requests are to be sent for the resolution of target protocol addresses to target hardware addresses for SVC connections. That server must have authoritative responsibility for resolving ARP requests of all IP stations within the LIS. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. 7. Packet Format Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams. This memo recognizes that other encapsulation methods may be used however, in the absence of other knowledge or agreement, LLC/SNAP encapsulation is the default. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this memo. 8. MTU Size The default MTU size for IP stations operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the default ATM AAL5 protocol data unit size is 9188 octets. In classical IP subnets, values other than the default can only be used if and only if all stations in the LIS have been configured to use the non- default value. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU size on a per-VC basis. Signalling negotiations are beyond the scope of this document. 9. ADDRESS RESOLUTION Laubach [Page 6] DRAFT Classical IP and ARP over ATM August 1993 Address resolution within an ATM logical IP subnet shall make use of the Address Resolution Protocol (ARP) [3] and the Inverse Address Resolution Protocol (InARP) [9] and all IP stations are required to support these protocols. Use of these protocols differ depending on whether permanent virtual circuits (PVC's) or switched virtual circuits (SVC's) are used. Permanent Virtual Circuits An IP station must have a mechanism for determining what PVC's it has, and in particular which PVC's are being used for LLC/SNAP encapsulated protocols. The details of the mechanism are beyond the scope of this memo. All IP stations supporting permanent virtual circuits are required to use the Inverse Address Resolution Protocol (InARP) as defined in [9] on those virtual circuits using LLC/SNAP encapsulation. In a strict PVC environment, the receiver shall infer the relevant virtual circuit from the virtual circuit on which the InARP request (InARP_REQUEST) or response (InARP_REPLY) was received. When the ATM source and/or target hardware address is unknown, the corresponding hardware address length in the InARP packet must be set to zero (0) indicating a null length, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InARP packet format details are presented later in this memo. From [9]: "When the requesting station receives the InARP reply, it may complete the ARP table entry and use the provided address information. Note: as with ARP, information learned via InARP may be aged or invalidated under certain circumstances." It is the responsibility of each IP station supporting ATM permanent virtual circuits to re-validate ARP table entries as part of the aging process. See the section below on "ARP Table Aging - All Stations". Switched Virtual Circuits ATM switched virtual circuits require support for ARP in the non- broadcast, non-multicast environment that ATM networks currently provide. To meet this need a single ARP server will be located within the LIS. This server must have authoritative responsibility for resolving the ARP requests of all IP stations within the LIS. The server itself is inherently passive in that it depends on the clients in the LIS to initiate the ARP registration procedure. An individual client connects to the ARP server using a point-to-point virtual circuit. The server, upon receiving a new virtual circuit specifying LLC/SNAP encapsulation, will initiate an InARP request to determine the IP address of the client. The InARP reply from the Laubach [Page 7] DRAFT Classical IP and ARP over ATM August 1993 client contains the information necessary for the ARP server to build its ARP table cache. This information is used to generate replies to the ARP requests it receives. The ARP server mechanism requires that each client be administratively configured with the ATM hardware address of the ARP server atm$arp-req as defined earlier in this memo. There is to be one and only one ARP server operational per logical IP subnet. This ARP server must be administratively configured so that it knows it is the ARP server. The ARP server MUST be configured with an IP address for each logical IP subnet it is serving to support InARP requests. This memo recognizes that a single ARP Server is not as robust as multiple servers which synchronize their databases correctly. This document is defining the client-server interaction by using a simple, single server approach as a reference model, and does not prohibit more robust approaches which use the same client-server interface. ARP Server Operational Requirements The ARP server accepts switched virtual circuit connections from other ATM stations. At call setup and if the VC supports LLC/SNAP encapsulation, the ARP server will transmit to the originating ATM station an InARP request (InARP_REQUEST) for each logical IP subnet the server is configured to serve. After receiving an InARP reply (InARP_REPLY), the server will examine the IP address and the ATM hardware address. The server will add (or update) the <hardware address, IP address> map entry and timestamp into its ARP table. If the InARP IP address duplicates a table entry IP address and the InARP hardware address does not match the table entry hardware address and there is an open virtual circuit associated with that table entry, the InARP information is discarded and no modifications to the table are made. ARP table entries persist until aged or invalidated. VC call tear down does not remove ARP table entries. The ARP server, upon receiving an ARP request (ARP_REQUEST), will generate the corresponding ARP reply (ARP_REPLY) if it has an entry in its ARP table or a negative ARP reply (ARP_NAK). The ARP_NAK response is an extension to the ARP protocol and is used to improve the robustness of the ARP server mechanism. With ARP_NAK, a client can determine the difference between a catastrophic server failure and an ARP table lookup failure. The ARP_NAK packet format is the same as the received ARP_REQUEST packet format with the operation code set to ARP_NAK, i.e., the ARP_REQUEST packet data is merely copied for transmission with the ARP_REQUEST operation code reset to ARP_NAK. ARP table information timeout update: when the server receives an ARP Laubach [Page 8] DRAFT Classical IP and ARP over ATM August 1993 request over a virtual circuit, and the source information (IP and hardware address) match the association already in the ARP table, and the hardware address matches that associated with the virtual circuit (in the SVC environment), then the server may update the timeout on the ARP table entry. ARP Client Operational Requirements The ARP client is responsible for contacting the ARP server to register its own ARP information and to gain and refresh ARP information about other IP stations. ARP clients are required to: 1. Initiate the virtual circuit connection to the ARP server for transmitting and receiving ARP and InARP packets. 2. Respond to ARP_REQUEST and InARP_REQUEST packets received on any VC appropriately. 3. Generate and transmit ARP_REQUEST packets to the ARP server and to process ARP_REPLY and ARP_NAK packets from the server appropriately. ARP_REPLY packets should be used to build/refresh ARP table entries. 4. Generate and transmit InARP_REQUEST packets as needed and to process InARP_REPLY packets appropriately. InARP_REPLY packets should be used to build/refresh ARP table entries. 5. Provide an ARP table aging function to remove old ARP tables entries after a convenient period of time. Note: if the client does not maintain an open VC to the server, the client must refresh its ARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InARP packets. ARP Table Aging - All stations A client or server must have knowledge of any open VC's it has (permanent or switched), their association with an ARP table entry, and in particular, which VC's support LLC/SNAP encapsulation. Client ARP table entries are valid for a maximum time of 15 minutes. Server ARP table entries are valid for a minimum time of 20 minutes. Prior to aging (removing) an ARP table entry, all stations must generate an InARP_REQUEST on any open VC associated with that entry. If an InARP_REPLY is received, that table entry is updated and not deleted. If there is no open VC associated with the table entry, the Laubach [Page 9] DRAFT Classical IP and ARP over ATM August 1993 entry is deleted. ARP and InARP Packet Format Internet addresses are assigned independent of ATM-FORUM NSAP addresses. Each host implementation MUST know its own internet and ATM address(es) and respond to address resolution requests appropriately. Hosts MUST also use ARP to map Internet addresses to ATM hardware addresses when needed. The ARP and InARP protocol has several fields that have the following format and values: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shln 8 bits Octet length of source hardware address (m) ar$spln 8 bits Octet length of source protocol address (n) ar$op 16 bits Operation code (request or reply) ar$thln 8 bits Octet length of target hardware address (p) ar$tpln 8 bits Octet length of target protocol address (q) ar$sha moctets source hardware address ar$spa noctets source protocol address ar$tha poctets target hardware address ar$tpa qoctets target protocol address Where: ar$hrd - assigned to ATM-FORUM NSAP address family and is dd decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$shln - length of the source hardware NSAP address length. ar$spln - length in bytes of the source protocol address. For IP ar$spln is 4. ar$op - The operation type value (decimal): ARP_REQUEST = 1 ARP_REPLY = 2 InARP_REQUEST = 8 InARP_REPLY = 9 ARP_NAK = ?? ar$thln - length of the target hardware NSAP address length. Laubach [Page 10] DRAFT Classical IP and ARP over ATM August 1993 ar$tpln - length in bytes of the target protocol address. For IP ar$tpln is 4. ar$sha - source NSAP address. ar$spa - source protocol address. ar$tha - target NSAP address. ar$tpa - target protocol address. The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be ATM-FORUM specified NSAP addresses [9]. The same NSAP encoding SHALL be used within an LIS and replies will use the same encoding as queries. For example, NSAP's may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 hardware addresses may be used but not both. ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDU's is: Payload Format for Routed non-ISO PDU's +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header. The OUI value of 0x00-00-00 (3 octets) indicates that the following two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 SDU. Laubach [Page 11] DRAFT Classical IP and ARP over ATM August 1993 The LLC/SNAP encapsulation for ARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks as specified in [5]. Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. It is conceivable in the future that larger scaled ATM networks may handle ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by ARP'ing outside the LIS or by a global ARP mechanism are beyond the scope of this memo. 10. IP Broadcast Address ATM does not support broadcast addressing, therefore there are no mappings available from IP broadcast addresses to ATM broadcast services. Note: this lack of mapping does not restrict stations from transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in [8]. Stations, upon receiving an IP broadcast or IP subnet broadcast for their LIS, must process the packet as if addressed to that station. 11. IP Multicast Address ATM does not support multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration. This memo recognizes the future development of ATM multicast service addressing by the ATM-FORUM. When available and widely implemented, the roll-over from the current IP multicast architecture to this new ATM architecture will be straightforward. 12. Security Security issues are not discussed in this memo. This memo recognizes the future development of ATM and IP facilities for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this memo. 13. Open Issues o A proposal was put before the Internet Assigned Numbers Authority Laubach [Page 12] DRAFT Classical IP and ARP over ATM August 1993 to approve a request to create an ARP hardware type of "ATM-FORUM NSAP address". IANA has not responded as of this date. o Well known ATM hardware address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Interim Local Management Interface (ILMI) services will not be generally implemented by some providers and vendors and will not be used to obtain the ATM address network prefix from the network [9]. Meta-signalling does provide some of this functionality and in the future we need to document the options. REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC1483, USC/Information Sciences Institute, July 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0. (DRAFT)", ATM-FORUM, 480 San Antonio Road, Suite 100, Mountain View, CA 94040, June 1993. Laubach [Page 13] DRAFT Classical IP and ARP over ATM August 1993 [10] Deering, S, "Host Extensions for IP Multicasting", RFC1112, USC/Information Sciences Institute, August 1989. [11] Colella, Richard, and Gardner, Ella, and Callon, Ross, "Guidelines for OSI NSAP Allocation in the Internet", RFC1237, USC/Information Sciences Institute, July 1991. Author's Address Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 14]